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Abstract 

DLV is an efficient iogic programming and non- 
monotonic reasoning (LPNMR) system with advanced 
knowledge representation mechanisms and interfaces to 
classic relational database systems. 
Its core language is disjunctive datalog (function-free 
disjunctive logic programming) under the Answer Set 
Semantics with integrity constraints, both default and 
strong (or explicit) negation, and queries. Integer 
arithmetics and various built-in predicates are also sup- 
ported. 

In addition DLV has several frontends, namely 
brave and cautious reasoning, abductive diagnosis, 
consistency-based diagnosis, a subset of SQL3, plan- 
ning with action languages, and logic programming 
with inheritance. 



General Information 

Currently DLV is available in binary form for var- 
ious platforms (sparc-sun-solaris2.6, alpha-dec-osf4.0, 
i386-linux-elf-gnulibc2, i386-pc-solaris2.7, and i386- 
unknown-freebsdelf3.3 as of this writing) and it is easy 
to build DLV on further platforms. 

Including all frontends, DLV consists of around 25000 
lines ISO C++ code plus several scanners and parsers 
written in lex/flex and yacc/bison, respectively. DLV 
is being developed using GNU tools (GCC, flex, and 
bison) and is therefore portable to most Unix-like plat- 
forms. Additionally, the system has been successfully 
built with proprietary compilers such as those of Com- 
paq and SCO. 

For up-to-date information on the system and a full 
manual please refer to the project homepage (Faber & 
Pfeifer since 1996), where you can also download DLV. 

"This work was supported by FWF (Austrian Science 
Funds) under the projects PI 1580- MAT and Z29-INF. 



Description of the System 
Kernel Language 

The kernel language of DLV is disjunctive datalog ex- 
tended with strong negation under the answer set se- 
mantics (Eiter, Gottlob, & Mannila 1997; Gelfond & 
Lifschitz 1991). 

Syntax Strings starting with uppercase letters denote 
variables, while those starting with lower case letters 
denote constants. A term is either a variable or a con- 
stant. An atom is an expression p(t\, . . .,t n ), where p is 
a predicate of arity n and t\,. . . ,t n are terms. A literal 
I is either an atom a (in this case, it is positive), or a 
negated atom —a (in this case, it is negative). 

Given a literal I, its complementary literal is defined 
as —a if I = a and a if I = —a. A set L of literals 
is said to be consistent if for every literal I € L, its 
complementary literal is not contained in L. 

In addition to literals as defined above, DLV also 
supports built-ins, like #int, #succ, <, +, and *. For 
details, we refer to our full manual (Faber & Pfeifer 
since 1996). 

A disjunctive rule (rule, for short) r is a formula 



oi v • • • v a n : - bi, ■ ■ ■ ,b k , not b k+ i, 



not bn 



where a\, ■ ■ ■ ,a n ,b\, ■ ■ ■ ,b m are literals, n > 0, m > 
k > 0, and not represents negation-as-failure (or default 
negation). The disjunction a\v ■ ■ ■ va n is the head of r, 
while the conjunction b\, b k , not bk+i, not b m is 
the body of r. A rule without head literals (i.e. n = 0) is 
usually referred to as integrity constraint. If the body 
is empty (i.e. k = m = 0), we usually omit the 
sign. 

We denote by H(r) the set of literals in the head, and 
by B(r) = B+(r) U B~ (r) the set of the body literals, 
where B+(r) = {b 1: . .., b k } and B~(r) = {b k+1 , 



b m } are the sets of positive and negative body literals, 
respectively. 

A disjunctive datalog program V is a finite set of rules. 

Semantics DLV implements the consistent answer 
sets semantics which has originally been defined in (Gel- 
fond & Lifschitz 1991). 1 

Before we are going to define this semantics, we need 
a few prerequisites. As usual, given a program V, Up 
(the Herbrand Universe) is the set of all constants ap- 
pearing in V and Bp (the Herbrand Base) is the set of 
all possible combinations of predicate symbols appear- 
ing in V with constants of Up possibly preceded by — , 
in other words, the set of ground literals constructible 
from the symbols in V '. 

Given a rule r, Ground(r) denotes the set of rules 
obtained by applying all possible substitutions a from 
the variables in r to elements of Up; Ground(r) is 
also called the Ground Instantiation of r. In a similar 
way, given a program V, Ground(V) denotes the set 

Ground(r). For programs not containing variables 

rev 

V = Ground(P) holds. 

For every program V , we define its answer sets using 
its ground instantiation Ground(V) in two steps, fol- 
lowing (Lifschitz 1996): First we define the answer sets 
of positive programs, then we give a reduction of gen- 
eral programs to positive ones and use this reduction to 
define answer sets of general programs. 

An interpretation / is a set of literals. A consistent 
interpretation / C Bp is called closed under a positive, 
i.e. not-free, program V, if, for every r £ Ground(V) 1 
H(r)CiI ^ whenever B(r) CI. I is an answer set for 
a positive program V if it is minimal w.r.t. set inclusion 
and closed under V '. 

The reductor Gelfond-Lifschitz transform of a general 
ground program V w.r.t. a set X C Bp is the positive 
ground program V x , obtained from V by deleting all 
rules r S V for which B~ (cjnl^O holds, and deleting 
the negative body from the remaining rules. 

An answer set of a general program V is a set X C Bp 
such that X is an answer set of Ground(V) x . 

Application Prontends 

In addition to its kernel language, DLV provides a num- 
ber of application frontends that show the suitability of 
our formalism for solving various problems from the ar- 
eas of Artificial Intelligence, Knowledge Representation 
and (Deductive) Databases. 

• The Brave and Cautious Frontends are simple ex- 
tensions of the normal mode, where in addition to a 
disjunctive datalog program the user specifies a con- 
junction of literals (a query) and DLV checks whether 
this query holds in any respectively all answer sets of 
the program. 

1 Note that we only consider consistent answer sets, while 
in (Lifschitz 1996) also the inconsistent set of all possible 
literals is a valid answer set. 



• The Diagnoses Frontend implements both abductive 
diagnosis (Poole 1989; Console, Theseider Dupre, & 
Torasso 1991), adapted to the semantics of logic pro- 
gramming (Kakas, Kowalski, & Toni 1993; Eiter, 
Gottlob, & Leone 1997), and consistency-based di- 
agnosis (Reiter 1987; de Kleer, Mackworth, & Reiter 
1992) and supports general diagnosis as well as single- 
failure and subset-minimal diagnosis. 

• The SQL3 Frontend is a prototype implementation 
of the query interface of the SQL3 standard that has 
been approved by ISO last year. 

• The Inheritance Frontend extends the kernel lan- 
guage of DLV with objects, and inheritance (Bucca- 
furri, Faber, & Leone 1999). This extension allows us 
to naturally represent inheritance and default reason- 
ing with (multi-level) exceptions, providing a natural 
solution also to the frame problem. 

• Finally, the Planning Frontend implements a new 
logic-based planning language, called K, which is well 
suited for planning under incomplete knowledge. 

Architecture 

An outline of the general architecture of our system is 
depicted in Fig.l. 

The heart of the system is the DLV core. Wrapped 
around this basic block are frontend preprocessors and 
output filters (which also do some post-processing for 
frontends). The system takes input data from the user 
(mostly via the command line) and from the file system 
and/or database systems. 

Upon startup, input is possibly translated by a fron- 
tend. Together with relational database tables, pro- 
vided by an Oracle database, an Objectivity database, 
or ASCII text files, the Intelligent Grounding Module, 
efficiently generates a subset of the grounded input pro- 
gram that has exactly the answer sets as the full pro- 
gram, but is much smaller in general. 

After that, the Model Generator is started. It gener- 
ates one answer set candidate at a time and verifies it 
using the Model Checker. Upon success, filtered output 
is generated for the answer set. This process is iterated 
until either no more answer sets exist or an explicitly 
specified number of answer sets has been computed. 

Not shown in Fig. 1 are various additional data struc- 
tures, such as dependency graphs. 

Applying the System 
Methodology 

The core language of DLV can be used to encode 
problems in a highly declarative fashion, following a 
"Guess&Check" paradigm. We will first describe this 
paradigm in an abstract way and then provide some 
concrete examples. We will see that several problems, 
also problems of high computational complexity, can be 
solved naturally in DLV by using this declarative pro- 
gramming technique. The power of disjunctive rules 
allows one to express problems, which are even more 
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Figure 1: Overall architecture of DLV. 



complex than NP uniformly over varying instances of 
the problem using a fixed program. 

Given a set Fi of facts that specify an instance / of 
some problem P, a Guess&Check program V for P 
consists of the following two parts: 

Guessing Part The guessing part G C V defines the 
search space, in a way such that answer sets of GUFi 
represent "solution candidates" of /. 

Checking Part The checking part C C V tests 
whether a solution candidate is in fact a solution, 
such that the answer sets of G U C U Fj represent the 
solutions for the problem instance I. 

In general, we may allow both G and C to be arbi- 
trary collections of rules in the program, and it may 
depend on the complexity of the problem which kind 
of rules are needed to realize these parts (in particular, 
the checking part); we defer this discussion to a later 
point in this section. 

Without imposing restrictions on which rules G and 
C may contain, in the extremal case we might set G 
to the full program and let C be empty, i.e., all check- 
ing is moved to the guessing part such that solution 
candidates are always solutions. This is certainly not 
intended. However, in general the generation of the 
search space may be guarded by some rules, and such 
rules might be considered more appropriately placed in 
the guessing part than in the checking part. We do not 
pursue this issue any further here, and thus also refrain 
from giving a formal definition of how to separate a 
program into a guessing and a checking part. 

For solving a number of problems, however, it is pos- 
sible to design a natural Guess&Check program in 
which the two parts are clearly identifiable and have a 



• The guessing part G consists of a disjunctive rule 
which "guesses" a solution candidate S. 

• The checking part C consists of integrity constraints 
which check the admissibility of S, possibly using 
auxiliary predicates which arc defined by normal 
stratified rules. 

In a sense, the disjunctive rule defines the search 
space in which rule applications are branching points, 
while the integrity constraints prune illegal branches. 

As a first example, let us consider Hamiltonian Path, 
a classical NP-complete problem from graph theory. 

HPATH: Given a directed graph G = (V, E) and a 
vertex a of this graph, does there exist a path of G start- 
ing at a and passing through each vertex in V exactly 
once? 

Suppose that the graph G is specified by means 
of predicates node (unary) and arc (binary), and 
the starting node is specified by the predicate start 
(unary). Then, the following Guess&Check program 
Vh P solves the Hamilton Path problem. 

inPath(X,Y) v outPath(X,Y) :- arc(X.Y) . 



inPath(X.Y), inPath(X.Yl) , Y <> Yl . 
inPath(X.Y) , inPath(Xl , Y) , X <> XI. 
node(X), not reached (X) . 
reached(X) :- start(X). 
reached(X) : - reached(Y) , inPath(Y.X) . 



> c 



The first rule guesses a subset of all given arcs, while 
the rest of the program checks whether it is a Hamilto- 
nian Path. Here, the checking part C uses an auxiliary 
predicate reached, which his defined using positive re- 
cursion. 

In particular, the first two constraints in C check 
whether the set of arcs S selected by inPath meets the 
following requirements, which any Hamiltonian Path 
must satisfy: There must not be two arcs starting at 
the same node, and there must not be two arcs ending 
in the same node. 

The two rules after the constraints define reachabil- 
ity from the starting node with respect to the selected 
arc set S. This is used in the third constraint, which 
enforces that all nodes in the graph are reached from 
the starting node in the subgraph induced by S. This 
constraint also ensures that this subgraph is connected. 

It is easy to see that a selected arc set S which sat- 
isfies all three constraints must contain the edges of a 
path a = Vo, i>i, • • • , Vk in G that starts at node a, and 
passes through distinct nodes until no further node is 
left, or it arrives at the starting node a again. In the 
latter case, this means that the path is a Hamiltonian 
Cycle, and by dropping the last edge, we have a Hamil- 
tonian Path. 

Thus, given a set of facts F for node, arc, and start 
which specify the problem input, the program Vh P U F 



has an answer set if and only if the input graph has a 
Hamiltonian Path. 

If we want to compute a Hamiltonian Path rather 
than only answering that such a path exists, we 
can strip off the last edge from a Hamiltonian Cy- 
cle by adding a further constraint :- start (Y), 
inPath(_,Y) . to the program. Then, the set S of se- 
lected edges in an answer sets of Vh P U F constitutes a 
Hamiltonian Path starting at a. 

It is worth noting that DLV is able to solve problems 
which are located at the second level of the polyno- 
mial hierarchy, and indeed also such problems can be 
encoded by the Guess&Check technique, as in the 
following example called Strategic Companies. 

STRATCOMP: Given the collection C = {a, 
. . . c m } of companies Cj owned by a holding, and in- 
formation about company control, compute the set of 
the strategic companies in the holding. 

To briefly explain what "strategic" means in this con- 
text, imagine that each company produces some goods. 
Moreover, several companies jointly may have control 
over another company. Now, some companies should 
be sold, under the constraint that all goods can be still 
produced, and that no company is sold which would 
still be controlled by the holding after the transaction. 
A company is strategic, if it belongs to a strategic set, 
which is a minimal set of companies satisfying these 
constraints. 

This problem is Sf-hard in general (Cadoli, Eiter, 
& Gottlob 1997); reformulated as a decision problem 
("Given a further company c in the input, is c strate- 
gic?"), it is £f -complete. To our knowledge, it is the 
only KR problem from the business domain of this com- 
plexity that has been considered so far. 

In the following encoding, strat(X) means that 
X is strategic, company(X) that X is a company, 
produced_by(X, Y, Z) that product X is produced by 
companies Y and Z, and controlled_by(W, X, Y, Z) that 
W is jointly controlled by X,Y and Z. We have adopted 
the setting from (Cadoli, Eiter, & Gottlob 1997) where 
each product is produced by at most two companies 
and each company is jointly controlled by at most three 
other companies. 

Given the facts F for company, controlledJby and 
•produced Jay, the answer sets of the following program 
VI (actually VI U F) correspond one-to-one to the 
strategic sets of the holding. Thus, the set of all strate- 
gic companies is given by the set of all companies c for 
which the fact strat(c) is true under brave reasoning. 

r: strat(Y) v strat(Z) : - produced_by(X, Y, Z). 

c: strat(W) :- controlled_by(W, X, Y, Z), 

strat(X), strat(Y), strat(Z). 

Intuitively, the guessing part G of VI consists of the 
disjunctive rule r, and the checking part C consist of the 
normal rule c. This program exploits the minimization 
which is inherent to the semantics of answer sets for 



the check whether a candidate set S of companies that 
produces all goods and obeys company control is also 
minimal with respect to this property. 

The guessing rule r intuitively selects one of the com- 
panies ci and c 2 that produce some item g, which 
is described by produced_by(g, ci, c 2 ). If there were 
no company control information, minimality of answer 
sets would then naturally ensure that the answer sets 
of F U {r} correspond to the strategic sets; no further 
checking is needed. However, in case such control in- 
formation, given by facts controlled_by(c, ci, c 2 , c 3 ), 
is available, the rule c in the program checks that no 
company is sold that would be controlled by other com- 
panies in the strategic set, by simply requesting that 
this company must be strategic as well. The minimal- 
ity of the strategic sets is automatically ensured by the 
minimality of answer sets. The answer sets of V2 cor- 
respond one-to-one to the strategic sets of the given 
instance. 

It is interesting to note that the checking constraint 
c interferes with the guessing rule r: applying c may 
spoil the minimal answer set generated by rule r. Such 
feedback from the checking part C to the guessing part 
G is in fact needed to solve E^-hard problems. 

In general, if a program encodes a problem that is 
Ef-complete, then the checking part C must contain 
disjunctive rules unless C has feedback to the guessing 
part G. 

Finally, note that STRATCOMP can not be ex- 
pressed by a fixed normal logic program uniformly 
on all collections of facts produced_by(p, cl, c2) and 
controlled_by(c, cl, c2,c3) (unless NP = Ef, an un- 
likely event). 

Specifics 

DLV is the result of putting theoretical results into 
practice. It is the first system supporting answer 
set semantics for full disjunctive logic programs with 
negation, integrity constraints, queries, and arithmetic 
built-ins. 

The semantics of the language is both precise and in- 
tuitive, which provides a clean, declarative, and easy-to 
use framework for knowledge representation and rea- 
soning. 

The availability of a system supporting such an ex- 
pressive language in an efficient way is stimulating AI 
and database people to use logic-based systems for the 
development of their applications. 

Furthermore, it is possible to formulate translations 
from many other formalisms to DLV's core language, 
such that the answer sets of the translated programs 
correspond to the solutions in the other formalism. 
DLV incorporates some of these translations as fron- 
tends. Currently frontends for diagnostic reasoning, 
SQL3, planning with action languages, and logic pro- 
gramming with inheritance exist. 

We believe that DLV can be used in this way - as 
a core engine - for many problem domains. The ad- 
vantage of this approach is that people with different 



background do not have to be aware of DLV's syntax 
and semantics. 

Users and Usability 

Prospective users of the DLV core system should have 
a basic knowledge of logics for knowledge representa- 
tion. As explained in the previous section, if a frontend 
for a particular language exists, a user need not even 
know about logics, but of course knowledge about the 
frontend language is still required. 

Currently, the DLV system is used for educational 
purposes in courses on Databases and on AI, both in 
European and American universities. It is also used 
by several researchers for knowledge representation, for 
verifying theoretical work, and for performance com- 
parisons. 

Furthermore, DLV is currently under evaluation at 
CERN, the European Laboratory for Particle Physics 
located near Geneva in Switzerland and France, for 
an advanced deductive database application that in- 
volves complex knowledge manipulations on large-sized 
databases. 

Evaluating the System 
Benchmarks 

It is a well-known in the area of benchmarking that 
the only really useful benchmark is the one where a 
(prospective) user of a system tests that system with 
exactly the kind of application he is going to use. 

Nevertheless, artificial benchmarks do have some 
merits in developing and improving the performance of 
systems. Moreover, they are also very useful in evalu- 
ating the progress of various implementations, so there 
has been some work in that area, too, and it seems that 
DLV compares favorably to similar systems (Eiter et 
al. 1998; Janhunen et al. 2000). 

Also for the development of some deductive database 
applications DLV can compete with database systems. 
Indeed, DLV is being considered by CERN for such 
an application which could not be handled by other 
systems. 

Problem Size 

As far as data structures are concerned, DLV does not 
have any real limit on the problem size it can handle. 
For example, we have verified current versions on pro- 
grams with 1 million literals in 1 million rules. 

Another crucial factor for hard input are suitable 
heuristics. Here we already have developed an inter- 
esting approach (Faber, Leone, & Pfeifcr 1999) and are 
actively working on various new approaches. 

To give an idea of the sizes of the problems that DLV 
can currently handle, and of the problems solvable by 
DLV in the near future, below we provide the execu- 
tion times of a number of hard benchmark instances 
reporting also the improvements over the last year. 
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"find one coloring of a random graph 

with 150 nodes and 350 edges 
fc find one Hamiltonian Path in a random graph 

with 25 nodes and 120 arcs 
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